SPACE 1

home *** CD-ROM | disk | FTP | other *** search

/ SPACE 1 / SPACE - Library 1 - Volume 1.iso / misc~1 / 199 / olddoc < prev next >

Wrap

Text File | 1988-03-14 | 11.6 KB | 248 lines

Mark Johnson's C (pak-870501) This contains a limited shareware C compiler for your use and enjoyment. You should find a number of file groups in this archive which contain the following: bin.arc cc.ttp - translates C code to intermediate code as.ttp - translates intermediate code to machine code hd.ttp - hex dump utility cat.ttp - file concatenation utility grep.ttp - utility to search for a string in a file ss.ttp - simple spreadsheet program mkt.bat - batch to compile "x.c" into "x.ttp" mkp.bat - batch to compile "x.c" into "x.prg" obj.bat - batch to compile "x.c" into "x.s" gemdemo.prg - file selector demo lib.arc prg.s - startup intermediate code for .PRG programs ttp.s - startup intermediate code for .TTP programs lib.a - used to create .TTP programs aes.a - aes calls and .PRG hooks vdi.a - all vdi calls lib.c - source for:lib.a aes.c - aes.a vdi.c - vdi.a stdio.h - standard i/o header used only in .TOS or .TTP gem.h - header used only in .PRG src.arc ss.c - a simple spreadsheet program cat.c - the file concat program grep.c - the string search program hd.c - the hex dump program gemdemo.c - outline of what MJC requires for GEM programs You will also find in the root directory: command.tos - public domain (PD) command line interpreter boot.bat - copy tools into the ramdisk desktop.inf - a custom setup needed by this package rmd209.acx - PD ramdisk for stock 520's rmd360k.acx - PD ramdisk for 1040's readme - this file SETTING UP -- When you de-arc this package, you will find three .ARC files and the six other files. First copy "command.tos", "boot.bat", and "desktop.inf" files to a blank, newly formatted disk. Then you may select the ramdisk you want from those provided, or one you may already have, and move it to the disk. If you use one of these ramdisks, make sure to change the extender to .ACC. Now, create three new folders on your disk. Name them "BIN", "LIB" and "SRC". Then de-arc each remaining .ARC into the respective folder. That is, de-arc "BIN.ARC" into folder "BIN" and so on. Find a good text on programming in "C" if you are unfamiliar with the language. I (M_Kg) suggest "C PRIMER PLUS" by Waite, Prata and Martin from Howard W. Sams & Co., Inc.; 1984. It is an easy to follow, friendly introduction to C written with a sense of humor but also serious enough to help those familiar with C. Also suggested (by M_J) is the C "bible" by Kerrington & Richie (See below). A text editor is also needed to create your C source code. Any editor which produces pure ASCII (meaning no control chars in the file except CR/LF and TAB) may be used. The microEMACS package available in ATARI16 of Compuserve is best. MARK JOHNSON'S "C" -- The compiler (cc.ttp) is preprocessor, parser, and code generator all rolled into a single program. Please refer to the "C Programming Language" by K&R. The compiler has the following features, limitations, and shortcomings: features - symbol names can be any length - built-in "trap" generator "trap(NUM, arg1, arg2, ...)" limitations - Only globals can be (very carefully) initialized. No type checking is done between the initializing value and the type of the global being initialized. This is crude but it works. Accepted initializer values are (long or short) constant expressions, strings, and symbols. what's missing - type specifiers: float double auto static - goto and labels - preprocessor: #undef and the #if family - structure assignments The output of the compiler is ascii text and each line maps into a single instruction. This intermediate code is as terse as I can make it (to save disk space) but is still readable (by me at least). (I have plans to improve this to make things easier for an optimizer). The output of the compiler is always placed in a file called "yc.out" in the current directory. Any error messages are displayed on the screen. Please note that the compiler output is unique and is not compatible with other assemblers for the ST. The assembler (as.ttp) reads the intermediate code in a single pass and keeps everything in memory before generating the file "ya.out" in the current directory. The size limit of the program to be compiled is basically the size of the available memory. The "ya.out" file should be renamed to one of the standard extensions (.TTP, .PRG, .TOS) before executing it. The command line of the assembler should always list a startup file first (see mkp.bat or mkt.bat) then the intermediate files of the program, then "-L" followed by any libraries. Any errors encountered by the assembler terminates assembly. A "-M" argument to the assembler will generate an address map of all global symbols in the file "ya.map". A library is simply intermediate code, but is handled differently by the assembler than regular intermediate code. Intermediate code (the files before "-L") are read and processed directly; all symbols and code are accepted without question. A library is read without processing until a symbol is found that is needed but not defined. From that point on, the library is read and processed until the next symbol is encountered. At the next symbol, the "needed but not defined" test is applied again and processing or scanning continues as necessary. The "intelligence" of the assembler insures the resulting programs are as compact as possible. The libraries include TOS, VDI, and AES routines taken from the Abacus books. I plan to document the library routines later. I have also included basic <stdio.h> routines. I have included the source for lib.a, aes.a, and vdi.a (see lib.c and aes.c, vdi.c). A lot of library routines you would expect to see are missing, and for that I apologize. Creating .TTP programs is straightforward and better tested than .PRG (GEM) program creation. In a .TTP process, the main function is called with the standard arguments: main(argc, argv) int argc; char *argv[]; Redirection of input and output using >outfile, >>appendfile, or <infile on the command line is handled by a startup routine linked into the compiled program. Reads and writes to the screen are built to map '\n' to/from "\n\r". GEM programs are called by: main() The argc and argv are not allowed at this time. Also, all input/output must be handled by GEMDOS, BIOS or XBIOS calls and not through "stdio.h" routines. Exiting through the "appl_exit" call is handled and should not be included in your program (see gemdemo.c). OTHER NOTES -- Support for GEM programs (.PRG) is not completely debugged. I have included the libraries but must honestly admit they are not yet ready. All of the routines found in the Abacus books are present in the library. The VDI routines are working. The window routines, form_alert, and evnt_multi of AES are working. My stumbling block right now is adequate documentation that would enable me to build a (working) Resource Construction Set. I'm working on it... RUNNING IT -- *From a Floppy Drive: Boot with the disk you created earlier. Then click on "BOOT.BAT" which will move all the needed files to the ramdisk. (You are using a ramdisk aren't you?) Now run "COMMAND.TOS". A .TTP window will open. Type either "mkp" for GEM programs or "mkt" for other programs (without the quotes) followed by the path and name of your C source code created earlier using your text editor. Be sure not to include the ".c" extender. Press return. Wait. If you made no mistakes (of course there are no mistakes) the result will be a runnable program! If you don't cold start to run this program, simply run "COMMAND.TOS" and then enter "boot" at the {A} prompt and continue from "mkp". *From a Hard Drive: Just change the BOOT.BAT file so it looks for the files on the correct drive and continue as above. For example: copy e:\lang\mjc\lib\*.a d: will move all the library precompiled files to the ramdisk when this package is stored in logical drive "E" in the "lang" folder as a "mjc" folder. Let me give you an example of how I use these tools. I normally place everything I need in the ramdisk before I start by using boot.bat. I then start command.tos, use "path d:", and insert a new working disk. I use microEMACS (available elsewhere) to create or edit C programs. If I have a program contained in a single file, I use either mkt.bat or mkp.bat to compile and link a .TTP or .PRG program, respectively. For example, mkt grep will compile the program grep.c and create an executable called grep.ttp. If the C program is contained in a number of files, I use obj.bat to create intermediate files having the same names as the C programs except for an .s extension. I then link them combining all the intermediate files together along with the necessary libraries. For example: as d:\ttp.s main.s io.s calc.s display.s -L d:\lib.a ren ya.out ss.ttp would serve as the command lines for a (mythical) spreadsheet program. ----- I bought my 520ST in April 1986. Almost all the software I have is either public domain or shareware. I have supported the shareware idea in the past, but I'd like to see it happen for myself. If you like what you find here, please send a donation along with your name and address. I'd like to run a newsletter to discuss bugs, enhancements, and hints. There is a lot I would like to do with this in the future. Many of the limitations are easy to fix, and I really do need a Resource Construction Set (if I can only figure out how to make object trees that work!). I hope you enjoy this software. It is not for sale by anyone, and I reserve all rights to its ownership. Feel free to pass it on to other ST owners, but please pass on the whole disk, including this "readme" file. I welcome any comments you may have; send mail to: Mark A. Johnson 85 Coleman Ave Red Bank, NJ 07701 ----- Hi, I have declared myself [un]official product rep for Mark Johnson's C here on CompuServe. This means I will post updates as they come out and hope to find a GEMDOS library to post here. If you have _minor_ problems, I might be able to help. However, I cannot help if you have _major_ problems. (Like form_alert accepting only constant strings) Please direct those types of bugs to Mark Johnson. As I become more familiar with this package, this may change, and of course, I am always happy to find out about anything you may discover (good or bad) about Mark Johnson's C. If you find this package helpful, useful, entertaining, or even completely useless, please consider a donation along with your comments and critical remarks. But do not send money to me, Mark Johnson is the one who deserves all the credit and reward for this product. I got my 1040ST in May 1986 and have been using it almost nonstop ever since, mostly to interface with the VAXnet at U of Houston and with CompuServe. The majority of my software, unlike Mark J's, is commercial. However, I feel just as strongly about the shareware concept. Having seen the work that went into this product, I am willing to support Mark J in his attempt to bring great software to ST users at a next-to-nothing price and I hope you will too. Mark Kelling [71550,1151] { Archive Updated 01 May 1987 with the newly revised GEM routines { Text of this file updated 03 May 1987.